|This page is dedicated to show
developers and users how to create the perfect app. It isn't as hard as it sounds. Here
you will find examples of over blown apps, and perfect ones, as well as guidelines or
creating your own app, and making it perfect. Let's get started.
..:: Guidelines ::.
Although there are many important things about the perfect app, there are 3 that stand
out the most. They don't apply to all apps, but here they are, in random order:
1. Interface. The interface is what makes an app pretty, or could ruin a good
app. I'm talking mainly about Win32 applications, since DOS apps usually are just run like
"delete /all". A good interface is a clean one. I have seen good apps with a not
so good interface, and also bad apps with a nice interface. Here is an ever-growing list
of things to do and not to do with your app's interface.
- Don't have your companies name written across the bottom of the app. Not only does it
make the interface that much uglier, but it makes the app look like shareware.
- Don't combine freeware and shareware. It is either absolutely free (no ads, no nag
screens, no registration), or it is shareware. Choose one or the other. Don't combine
- Don't use 16 bit icons, unless it is only for Windows 95. Windows 98 + can use 32 bit
icons. 32 bit icons look nicer than the 16 bit ones. If you can, 32 bit icons are the way
- Test your app in: small fonts, large fonts, and different screen resolutions before
releasing it. On my system, I use large fonts most of the time. Some apps have to be
resized immediately after they are opened, because the text cuts off. Not very attractive.
- Don't over due the interface. Just because you can doesn't mean you should. Just because
you learned from a top secret Visual Basic site how to customize a scrollbar doesn't mean
you should add one in. See the [ Examples ] page for some apps to learn from.
- Make it clean. Don't use a bunch of different fonts throughout the program. Don't use
every possible color you can on the app. Have some sort of theme. The more you add to an
app, the slower it loads, and the bigger it is. Keep it simple.
2. Stability. Even if an app has a perfect interface, you don't want it crashing
every three seconds. If someone is reading through Download.com's comments section on an
app, and hears one thing about crashing a computer, it probably won't be downloaded.
- Stay away from window animation. All the newbie programmers all want to have their app
fall in from the top of the screen. If this app is frequently used, this gets really
annoying. Unless you know what you are doing, stay away from it. See [ Examples ]
- Don't release an unstable program, unless it is an alpha / beta. In testing, bugs are
usually excused. On final releases, however, they are not. Nobody wants their app to have
a bad first impression.
- Test is on different computers with different operating systems. You may find out that
you need a certain file to make it run, that your computer has, but others don't.
- If your app is incompatible with another program, say that in the readme. Better the end
user knowing before, than having it crash.
3. Features / Usefulness. Your app has to do something. And it should be good at
what is does.
- Don't combine a bunch of features into one app, unless it makes sense. Would you use a
toaster built into a car? Probably not. An app that minimizes all windows shouldn't have a
feature to stick Post-it notes on the desktop, or launch Word. The exception is all-in-one
apps like Power Tools. See [ Examples ]
- Decide whether or not to make it customizable. An app that launches notepad probably
shouldn't have any options. An app that is bigger and more advanced should usually have
options. But don't have too many options. The more options, the harder the program is to
learn, and could put stability at risk.
- Your program should be useful. If it isn't there is no sense having it. It should also
be good at what it does. A couple people might want a program that skips ahead 4.5 seconds
while Winamp is playing a 128-bit WMA file, but most people won't really care about that.
- Show how the features work. In a help file, readme, or website. There's no sense having
loads of features, but no clue what they do.
[ Questions ]